When initiating a media stream session, for example multimedia teleconferences, voice-over-IP calls, streaming video and/or audio, there is a need to convey session information, for example media details, addresses, or other session description information, to the participants of the session.
SDP is a format or protocol for describing media stream initialization parameters. SDP is not in itself a transport protocol and is purely for session description, irrespective of how the streaming media is to be transported.
Simply providing media stream descriptions is sufficient for session announcements in a broadcast application, where the media stream parameters are fixed for all participants. When a participant wants to join the session, he/she obtains the session announcement and uses the media descriptions provided, e.g., joining a multicast group and receiving media packets in the encoding format specified. If the media stream description is not supported by the participant, he is unable to receive the media.
Such restrictions are not generally acceptable to multimedia session invitations, where two or more entities attempt to establish a media session using a set of media stream parameters acceptable to all participants. Firstly, each entity must inform the other of its details, e.g. receive address, and secondly, the entities need to agree on the media stream parameters to use for the session, e.g. transport protocols and codecs. A distinction is made between the capabilities supported by each participant and the media stream parameters that are actually used for the session.
SDP is intended to be general-purpose so that it can be used in a wide range of network environment and applications. However RFC 2327 and its update RFC 4566, an Internet Proposed Standard document which defines SDP is not defined to support negotiation of session content or media encodings.
RFC 3264, the offer/answer model, defines a limited session negotiation model for use with SDP, however, there is currently no well-defined way to: negotiate alternative transport protocols (e.g. RTP profiles such as RTP/AVP and RTP/SAVP); negotiate alternative combinations of transport protocols and media types (e.g. RTP/AVP and “audio” for voice-band data or T.38 and “image” for fax relay); negotiate alternative media formats (e.g. codecs) without committing to use all of them at the same time (e.g. indicating support of PCMU and G.729 would indicate that either can be used with a switch on-the-fly based on observed payload type only); or negotiate unicast and multicast addresses as alternative transport addresses.